GGGGLLLL____GGGGRRRREEEEEEEENNNN, GGGGLLLL____BBBBLLLLUUUUEEEE, GGGGLLLL____AAAALLLLPPPPHHHHAAAA, GGGGLLLL____LLLLUUUUMMMMIIIINNNNAAAANNNNCCCCEEEE, and
GGGGLLLL____LLLLUUUUMMMMIIIINNNNAAAANNNNCCCCEEEE____AAAALLLLPPPPHHHHAAAA are accepted.
_t_y_p_e Specifies the data type for _p_i_x_e_l_s. Symbolic constants
GGGGLLLL____UUUUNNNNSSSSIIIIGGGGNNNNEEEEDDDD____IIIINNNNTTTT____11110000____11110000____11110000____2222, and
GGGGLLLL____UUUUNNNNSSSSIIIIGGGGNNNNEEEEDDDD____IIIINNNNTTTT____2222____11110000____11110000____11110000____RRRREEEEVVVV are accepted.
_p_i_x_e_l_s Specifies a pointer to the pixel data.
DDDDEEEESSSSCCCCRRRRIIIIPPPPTTTTIIIIOOOONNNN
ggggllllDDDDrrrraaaawwwwPPPPiiiixxxxeeeellllssss reads pixel data from memory and writes it into the frame
buffer relative to the current raster position, provided that the raster
position is valid. Use ggggllllRRRRaaaasssstttteeeerrrrPPPPoooossss to set the current raster position;
use ggggllllGGGGeeeetttt with argument GGGGLLLL____CCCCUUUURRRRRRRREEEENNNNTTTT____RRRRAAAASSSSTTTTEEEERRRR____PPPPOOOOSSSSIIIITTTTIIIIOOOONNNN____VVVVAAAALLLLIIIIDDDD to determine if
the specified raster position is valid, and ggggllllGGGGeeeetttt with argument
GGGGLLLL____CCCCUUUURRRRRRRREEEENNNNTTTT____RRRRAAAASSSSTTTTEEEERRRR____PPPPOOOOSSSSIIIITTTTIIIIOOOONNNN to query the raster position.
Several parameters define the encoding of pixel data in memory and
control the processing of the pixel data before it is placed in the frame
buffer. These parameters are set with four commands: ggggllllPPPPiiiixxxxeeeellllSSSSttttoooorrrreeee,
ggggllllPPPPiiiixxxxeeeellllTTTTrrrraaaannnnssssffffeeeerrrr, ggggllllPPPPiiiixxxxeeeellllMMMMaaaapppp, and ggggllllPPPPiiiixxxxeeeellllZZZZoooooooommmm. This reference page
describes the effects on ggggllllDDDDrrrraaaawwwwPPPPiiiixxxxeeeellllssss of many, but not all, of the
GGGGLLLL____UUUUNNNNSSSSIIIIGGGGNNNNEEEEDDDD____IIIINNNNTTTT____8888____8888____8888____8888____RRRREEEEVVVV, GGGGLLLL____UUUUNNNNSSSSIIIIGGGGNNNNEEEEDDDD____IIIINNNNTTTT____2222____11110000____11110000____11110000____RRRREEEEVVVV, each
unsigned value is interpreted as containing all color components,
specified by _f_o_r_m_a_t, for a single pixel in a reversed order. Indices are
always treated individually. Color components are treated as groups of
one, two, three, or four values, again based on _f_o_r_m_a_t. Both individual
indices and groups of components are referred to as pixels. If _t_y_p_e is
GGGGLLLL____BBBBIIIITTTTMMMMAAAAPPPP, the data must be unsigned bytes, and _f_o_r_m_a_t must be either
GGGGLLLL____CCCCOOOOLLLLOOOORRRR____IIIINNNNDDDDEEEEXXXX or GGGGLLLL____SSSSTTTTEEEENNNNCCCCIIIILLLL____IIIINNNNDDDDEEEEXXXX. Each unsigned byte is treated as
eight 1-bit pixels, with bit ordering determined by GGGGLLLL____UUUUNNNNPPPPAAAACCCCKKKK____LLLLSSSSBBBB____FFFFIIIIRRRRSSSSTTTT
(see ggggllllPPPPiiiixxxxeeeellllSSSSttttoooorrrreeee).
_w_i_d_t_h x _h_e_i_g_h_t pixels are read from memory, starting at location _p_i_x_e_l_s.
By default, these pixels are taken from adjacent memory locations, except
that after all _w_i_d_t_h pixels are read, the read pointer is advanced to the
next four-byte boundary. The four-byte row alignment is specified by
ggggllllPPPPiiiixxxxeeeellllSSSSttttoooorrrreeee with argument GGGGLLLL____UUUUNNNNPPPPAAAACCCCKKKK____AAAALLLLIIIIGGGGNNNNMMMMEEEENNNNTTTT, and it can be set to one,
two, four, or eight bytes. Other pixel store parameters specify
different read pointer advancements, both before the first pixel is read
and after all _w_i_d_t_h pixels are read. See the ggggllllPPPPiiiixxxxeeeellllSSSSttttoooorrrreeee reference page
for details on these options.
The _w_i_d_t_h x _h_e_i_g_h_t pixels that are read from memory are each operated on
in the same way, based on the values of several parameters specified by
ggggllllPPPPiiiixxxxeeeellllTTTTrrrraaaannnnssssffffeeeerrrr and ggggllllPPPPiiiixxxxeeeellllMMMMaaaapppp. The details of these operations, as well
as the target buffer into which the pixels are drawn, are specific to the
format of the pixels, as specified by _f_o_r_m_a_t. _f_o_r_m_a_t can assume one of
Each fixed-point index is then shifted left by GGGGLLLL____IIIINNNNDDDDEEEEXXXX____SSSSHHHHIIIIFFFFTTTT
bits and added to GGGGLLLL____IIIINNNNDDDDEEEEXXXX____OOOOFFFFFFFFSSSSEEEETTTT. If GGGGLLLL____IIIINNNNDDDDEEEEXXXX____SSSSHHHHIIIIFFFFTTTT is
negative, the shift is to the right. In either case, zero bits
fill otherwise unspecified bit locations in the result.
If the GL is in RGBA mode, the resulting index is converted to
an RGBA pixel with the help of the GGGGLLLL____PPPPIIIIXXXXEEEELLLL____MMMMAAAAPPPP____IIII____TTTTOOOO____RRRR,
GGGGLLLL____PPPPIIIIXXXXEEEELLLL____MMMMAAAAPPPP____IIII____TTTTOOOO____GGGG, GGGGLLLL____PPPPIIIIXXXXEEEELLLL____MMMMAAAAPPPP____IIII____TTTTOOOO____BBBB, and
GGGGLLLL____PPPPIIIIXXXXEEEELLLL____MMMMAAAAPPPP____IIII____TTTTOOOO____AAAA tables. If the GL is in color index mode,
and if GGGGLLLL____MMMMAAAAPPPP____CCCCOOOOLLLLOOOORRRR is true, the index is replaced with the
value that it references in lookup table GGGGLLLL____PPPPIIIIXXXXEEEELLLL____MMMMAAAAPPPP____IIII____TTTTOOOO____IIII.
Whether the lookup replacement of the index is done or not, the
b
integer part of the index is then ANDed with 2 -1, where b is
the number of bits in a color index buffer.
The GL then converts the resulting indices or RGBA colors to
fragments by attaching the current raster position _z coordinate
and texture coordinates to each pixel, then assigning x and y
window coordinates to the nth fragment such that
x = x + n mod width
n r
y = y + |n/width |
n r
where (x ,y ) is the current raster position. These pixel
r r
fragments are then treated just like the fragments generated by
rasterizing points, lines, or polygons. Texture mapping, fog,
and all the fragment operations are applied before the
The rasterization described so far assumes pixel zoom factors of 1. If
ggggllllPPPPiiiixxxxeeeellllZZZZoooooooommmm is used to change the x and y pixel zoom factors, pixels are
converted to fragments as follows. If (x , y ) is the current raster
r r
position, and a given pixel is in the nth column and mth row of the pixel
rectangle, then fragments are generated for pixels whose centers are in
the rectangle with corners at
(x + zoom n, y + zoom m)
r x r y
(x + zoom (n + 1), y + zoom (m + 1))
r x r y
where zoom is the value of GGGGLLLL____ZZZZOOOOOOOOMMMM____XXXX and zoom is the value of
x y
GGGGLLLL____ZZZZOOOOOOOOMMMM____YYYY.
When GGGGLLLL____IIIINNNNTTTTEEEERRRRLLLLAAAACCCCEEEE____SSSSGGGGIIIIXXXX is enabled, every other row of the destination
pixel rectangle is modified. The height of the pixel rectangle is
equivalent to 2xGGGGLLLL____ZZZZOOOOOOOOMMMM____YYYYxheight. Only rows (y +0,y +2,...) are affected
r r
by the draw operation.
Normally ggggllllDDDDrrrraaaawwwwPPPPiiiixxxxeeeellllssss is synchronous: OpenGL executes a ggggllllDDDDrrrraaaawwwwPPPPiiiixxxxeeeellllssss
command in the order it is issued in the OpenGL command stream. Calling
ggggllllEEEEnnnnaaaabbbblllleeee with parameter GGGGLLLL____AAAASSSSYYYYNNNNCCCC____DDDDRRRRAAAAWWWW____PPPPIIIIXXXXEEEELLLLSSSS____SSSSGGGGIIIIXXXX causes subsequent
ggggllllDDDDrrrraaaawwwwPPPPiiiixxxxeeeellllssss commands to be asynchronous as defined by the SSSSGGGGIIIIXXXX____aaaassssyyyynnnncccc
extension. An asynchronous ggggllllDDDDrrrraaaawwwwPPPPiiiixxxxeeeellllssss command samples the OpenGL state
vector at the point in the OpenGL command stream where the command is
issued, but the results of the command (e.g. updates to the frame buffer)
do not happen until some unspecified time in the future. In particular,
the order of the asynchronous command relative to other OpenGL commands
issued later in the command stream is undefined. An implementation may
choose to execute asynchronous commands in parallel with the normal
command stream or at some convenient time in the future.
Calling ggggllllDDDDiiiissssaaaabbbblllleeee with parameter GGGGLLLL____AAAASSSSYYYYNNNNCCCC____DDDDRRRRAAAAWWWW____PPPPIIIIXXXXEEEELLLLSSSS____SSSSGGGGIIIIXXXX restores the
default synchronous behavior for subsequent ggggllllDDDDrrrraaaawwwwPPPPiiiixxxxeeeellllssss commands. It
does not affect any pending asynchronous ggggllllDDDDrrrraaaawwwwPPPPiiiixxxxeeeellllssss commands, or wait
When an asynchronous ggggllllDDDDrrrraaaawwwwPPPPiiiixxxxeeeellllssss command is issued, it is associated
with the current value of GGGGLLLL____AAAASSSSYYYYNNNNCCCC____MMMMAAAARRRRKKKKEEEERRRR____SSSSGGGGIIIIXXXX as defined by the
SSSSGGGGIIIIXXXX____aaaassssyyyynnnncccc extension. A program can determine if an asynchronous
ggggllllDDDDrrrraaaawwwwPPPPiiiixxxxeeeellllssss command has completed by using the ggggllllFFFFiiiinnnniiiisssshhhhAAAAssssyyyynnnnccccSSSSGGGGIIIIXXXX or
GGGGLLLL____UUUUNNNNSSSSIIIIGGGGNNNNEEEEDDDD____IIIINNNNTTTT____11110000____11110000____11110000____2222, and GGGGLLLL____UUUUNNNNSSSSIIIIGGGGNNNNEEEEDDDD____IIIINNNNTTTT____2222____11110000____11110000____11110000____RRRREEEEVVVV are only
valid for _t_y_p_e if the GL version is 1.2 or greater.
EEEERRRRRRRROOOORRRRSSSS
GGGGLLLL____IIIINNNNVVVVAAAALLLLIIIIDDDD____VVVVAAAALLLLUUUUEEEE is generated if either _w_i_d_t_h or _h_e_i_g_h_t is negative.
GGGGLLLL____IIIINNNNVVVVAAAALLLLIIIIDDDD____EEEENNNNUUUUMMMM is generated if _f_o_r_m_a_t or _t_y_p_e is not one of the accepted
values.
GGGGLLLL____IIIINNNNVVVVAAAALLLLIIIIDDDD____OOOOPPPPEEEERRRRAAAATTTTIIIIOOOONNNN is generated if _f_o_r_m_a_t is GGGGLLLL____RRRREEEEDDDD, GGGGLLLL____GGGGRRRREEEEEEEENNNN, GGGGLLLL____BBBBLLLLUUUUEEEE,
GGGGLLLL____AAAALLLLPPPPHHHHAAAA, GGGGLLLL____RRRRGGGGBBBB, GGGGLLLL____RRRRGGGGBBBBAAAA, GGGGLLLL____BBBBGGGGRRRR, GGGGLLLL____BBBBGGGGRRRRAAAA, GGGGLLLL____AAAABBBBGGGGRRRR____EEEEXXXXTTTT, GGGGLLLL____LLLLUUUUMMMMIIIINNNNAAAANNNNCCCCEEEE, or
GGGGLLLL____LLLLUUUUMMMMIIIINNNNAAAANNNNCCCCEEEE____AAAALLLLPPPPHHHHAAAA, and the GL is in color index mode.
GGGGLLLL____IIIINNNNVVVVAAAALLLLIIIIDDDD____EEEENNNNUUUUMMMM is generated if _t_y_p_e is GGGGLLLL____BBBBIIIITTTTMMMMAAAAPPPP and _f_o_r_m_a_t is not
either GGGGLLLL____CCCCOOOOLLLLOOOORRRR____IIIINNNNDDDDEEEEXXXX or GGGGLLLL____SSSSTTTTEEEENNNNCCCCIIIILLLL____IIIINNNNDDDDEEEEXXXX.
GGGGLLLL____IIIINNNNVVVVAAAALLLLIIIIDDDD____OOOOPPPPEEEERRRRAAAATTTTIIIIOOOONNNN is generated if _f_o_r_m_a_t is GGGGLLLL____SSSSTTTTEEEENNNNCCCCIIIILLLL____IIIINNNNDDDDEEEEXXXX and there
is no stencil buffer.
GGGGLLLL____IIIINNNNVVVVAAAALLLLIIIIDDDD____OOOOPPPPEEEERRRRAAAATTTTIIIIOOOONNNN is generated if ggggllllDDDDrrrraaaawwwwPPPPiiiixxxxeeeellllssss is executed between the
execution of ggggllllBBBBeeeeggggiiiinnnn and the corresponding execution of ggggllllEEEEnnnndddd.
GGGGLLLL____IIIINNNNVVVVAAAALLLLIIIIDDDD____OOOOPPPPEEEERRRRAAAATTTTIIIIOOOONNNN is generated if _f_o_r_m_a_t is one
GGGGLLLL____UUUUNNNNSSSSIIIIGGGGNNNNEEEEDDDD____SSSSHHHHOOOORRRRTTTT____5555____6666____5555, of GGGGLLLL____UUUUNNNNSSSSIIIIGGGGNNNNEEEEDDDD____SSSSHHHHOOOORRRRTTTT____5555____6666____5555____RRRREEEEVVVV and _f_o_r_m_a_t is not
GGGGLLLL____RRRRGGGGBBBB.
GGGGLLLL____IIIINNNNVVVVAAAALLLLIIIIDDDD____OOOOPPPPEEEERRRRAAAATTTTIIIIOOOONNNN is generated if _f_o_r_m_a_t is one of
GGGGLLLL____UUUUNNNNSSSSIIIIGGGGNNNNEEEEDDDD____IIIINNNNTTTT____11110000____11110000____11110000____2222, or GGGGLLLL____UUUUNNNNSSSSIIIIGGGGNNNNEEEEDDDD____IIIINNNNTTTT____2222____11110000____11110000____11110000____RRRREEEEVVVV and _f_o_r_m_a_t
is not GGGGLLLL____RRRRGGGGBBBBAAAA, GGGGLLLL____BBBBGGGGRRRRAAAA or GGGGLLLL____AAAABBBBGGGGRRRR____EEEEXXXXTTTT.
GGGGLLLL____IIIINNNNVVVVAAAALLLLIIIIDDDD____OOOOPPPPEEEERRRRAAAATTTTIIIIOOOONNNN is generated when the SSSSGGGGIIIIXXXX____ssssuuuubbbbssssaaaammmmpppplllleeee extension is
supported, and the pixel storage mode GGGGLLLL____UUUUNNNNPPPPAAAACCCCKKKK____SSSSUUUUBBBBSSSSAAAAMMMMPPPPLLLLEEEE____RRRRAAAATTTTEEEE____SSSSGGGGIIIIXXXX is
not GGGGLLLL____PPPPIIIIXXXXEEEELLLL____SSSSUUUUBBBBSSSSAAAAMMMMPPPPLLLLEEEE____4444444444444444____SSSSGGGGIIIIXXXX, and _w_i_d_t_h is not a multiple of 2, or
_f_o_r_m_a_t is not a 3 or 4 component format, or _t_y_p_e is a packed pixels type.
GGGGLLLL____IIIINNNNVVVVAAAALLLLIIIIDDDD____OOOOPPPPEEEERRRRAAAATTTTIIIIOOOONNNN is generated if GGGGLLLL____AAAASSSSYYYYNNNNCCCC____DDDDRRRRAAAAWWWW____PPPPIIIIXXXXEEEELLLLSSSS____SSSSGGGGIIIIXXXX is enabled
and the number of asynchronous ggggllllDDDDrrrraaaawwwwPPPPiiiixxxxeeeellllssss commands that have been
issued but not queried (using ggggllllFFFFiiiinnnniiiisssshhhhAAAAssssyyyynnnnccccSSSSGGGGIIIIXXXX or ggggllllPPPPoooollllllllAAAAssssyyyynnnnccccSSSSGGGGIIIIXXXX)
ggggllllGGGGeeeetttt with argument GGGGLLLL____CCCCUUUURRRRRRRREEEENNNNTTTT____RRRRAAAASSSSTTTTEEEERRRR____PPPPOOOOSSSSIIIITTTTIIIIOOOONNNN
ggggllllGGGGeeeetttt with argument GGGGLLLL____CCCCUUUURRRRRRRREEEENNNNTTTT____RRRRAAAASSSSTTTTEEEERRRR____PPPPOOOOSSSSIIIITTTTIIIIOOOONNNN____VVVVAAAALLLLIIIIDDDD
ggggllllGGGGeeeetttt with argument GGGGLLLL____IIIINNNNTTTTEEEERRRRLLLLAAAACCCCEEEE____SSSSGGGGIIIIXXXX
On RRRReeeeaaaalllliiiittttyyyyEEEEnnnnggggiiiinnnneeee, RRRReeeeaaaalllliiiittttyyyyEEEEnnnnggggiiiinnnneeee2222, and VVVVTTTTXXXX systems convolution may not be
used in the following circumstances:
1. When rendering to pixmaps.
2. When fragment processing (texturing, depth buffering, alpha
testing, multisampling, fog) is enabled.
3. When histogramming or minmax is enabled.
4. When either of the pixel zoom factors has a value other than 1.0
or -1.0.
In these cases, ggggllllDDDDrrrraaaawwwwPPPPiiiixxxxeeeellllssss and ggggllllCCCCooooppppyyyyPPPPiiiixxxxeeeellllssss report a
GGGGLLLL____IIIINNNNVVVVAAAALLLLIIIIDDDD____OOOOPPPPEEEERRRRAAAATTTTIIIIOOOONNNN error and do not transfer any pixels.
Performance note for RRRReeeeaaaalllliiiittttyyyyEEEEnnnnggggiiiinnnneeee, RRRReeeeaaaalllliiiittttyyyyEEEEnnnnggggiiiinnnneeee2222, and VVVVTTTTXXXX systems:
Unsigned color types use the fastest pixel-drawing path. Smaller types
(e.g., GGGGLLLL____UUUUNNNNSSSSIIIIGGGGNNNNEEEEDDDD____BBBBYYYYTTTTEEEE) require less host-to-graphics bandwidth, and are
therefore faster than larger types (e.g., GGGGLLLL____UUUUNNNNSSSSIIIIGGGGNNNNEEEEDDDD____IIIINNNNTTTT). Signed and
float types use the significantly slower floating-point pixel-drawing
path. The slower pixel-drawing path is also used when the format is
GGGGLLLL____DDDDEEEEPPPPTTTTHHHH____CCCCOOOOMMMMPPPPOOOONNNNEEEENNNNTTTT and when fragment operations (i.e., depth or alpha
testing, texturing, fog, etc.) are enabled.
For best performance on XXXXSSSS, XXXXZZZZ, EEEEllllaaaannnn, and EEEExxxxttttrrrreeeemmmmeeee systems set type to
GGGGLLLL____UUUUNNNNSSSSIIIIGGGGNNNNEEEEDDDD____BBBBYYYYTTTTEEEE and, when drawing to the color buffer, set format to
On IIIInnnnffffiiiinnnniiiitttteeeeRRRReeeeaaaalllliiiittttyyyy systems, signed color-index pixels written to
drawables with dual-personality (luminance + color-index) visuals will be
sign-extended into the high-order bits of the framebuffer. For example,
writing a signed byte value of 0x88 would yield 0xF88 in a 12-bit
drawable.
The SSSSGGGGIIIIXXXX____yyyyccccrrrrccccbbbb extension is supported only on OOOO2222 systems. When using
GGGGLLLL____YYYYCCCCRRRRCCCCBBBB____444422222222____SSSSGGGGIIIIXXXX with ggggllllDDDDrrrraaaawwwwPPPPiiiixxxxeeeellllssss on OOOO2222 systems, an odd integer value
for GGGGLLLL____UUUUNNNNPPPPAAAACCCCKKKK____SSSSKKKKIIIIPPPP____PPPPIIIIXXXXEEEELLLLSSSS will be set to the next highest even integer
value to preserve color alignment.
On CRIME systems with a Crime Revision of 1.0-1.3, the SSSSGGGGIIIIXXXX____yyyyccccrrrrccccbbbb
extension will generate incorrect RGB colors from video with highly
saturated blue or red values. Commonly, the blue of a very saturated sky
will be converted to a pale yellow. This problem is fixed with the CRIME
1.4 graphics.
On OOOOccccttttaaaannnneeee2222 VVVVPPPPrrrroooo systems the format GGGGLLLL____DDDDEEEEPPPPTTTTHHHH____CCCCOOOOMMMMPPPPOOOONNNNEEEENNNNTTTT22224444____SSSSGGGGIIIIXXXX can be used
to transfer depth pixel values to and from the depth buffer in their
internal eye-space range. There are performance advantages over
transfers that convert to screen-space values, particularly for
GGGGLLLL____UUUUNNNNSSSSIIIIGGGGNNNNEEEEDDDD____IIIINNNNTTTT type pixels.
The SSSSGGGGIIIIXXXX____iiiinnnntttteeeerrrrllllaaaacccceeee extension is supported only on IIIInnnnffffiiiinnnniiiitttteeeeRRRReeeeaaaalllliiiittttyyyy
systems, on RRRReeeeaaaalllliiiittttyyyyEEEEnnnnggggiiiinnnneeee, RRRReeeeaaaalllliiiittttyyyyEEEEnnnnggggiiiinnnneeee2222, and VVVVTTTTXXXX systems, on OOOOccccttttaaaannnneeee2222
VVVVPPPPrrrroooo systems, and on OOOO2222 systems.
The EEEEXXXXTTTT____ppppaaaacccckkkkeeeedddd____ppppiiiixxxxeeeellllssss extension is not supported on RRRReeeeaaaalllliiiittttyyyyEEEEnnnnggggiiiinnnneeee,
RRRReeeeaaaalllliiiittttyyyyEEEEnnnnggggiiiinnnneeee2222, and VVVVTTTTXXXX systems.
The SSSSGGGGIIIIXXXX____ssssuuuubbbbssssaaaammmmpppplllleeee and SSSSGGGGIIIIXXXX____rrrreeeessssaaaammmmpppplllleeee extensions are supported only on
OOOOccccttttaaaannnneeee2222 VVVVPPPPrrrroooo systems. Applying the GGGGLLLL____PPPPIIIIXXXXEEEELLLL____SSSSUUUUBBBBSSSSAAAAMMMMPPPPLLLLEEEE____2222444422224444____SSSSGGGGIIIIXXXX
subsample rate is accelerated for direct immmediate mode transfers when
the format is GGGGLLLL____RRRRGGGGBBBB or GGGGLLLL____RRRRGGGGBBBBAAAA, and the type is GGGGLLLL____UUUUNNNNSSSSIIIIGGGGNNNNEEEEDDDD____BBBBYYYYTTTTEEEE or
